home *** CD-ROM | disk | FTP | other *** search
/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.385 < prev    next >
Text File  |  1996-02-12  |  29KB  |  619 lines
  1. Frequently Asked Questions (FAQS);faqs.385
  2.  
  3.  
  4.  
  5. FAQ lists are intended to reduce the noise level in their newsgroups
  6. that results from the repetition of the same questions, correct answers,
  7. wrong answers, corrections to the wrong answers, corrections to the
  8. corrections, debate, etc.
  9.  
  10. This list should serve as a repository of the canonical "best" answers
  11. to the questions in it.  The names of folks who have helped to improve
  12. this FAQ list follow the table of contents.  If you know a better answer
  13. or even a slight change that improves an answer, please tell me!  (Use
  14. email, please.  Traffic in this group is high, and I may miss a relevant
  15. posted article.)
  16.                       Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
  17.                                                         brown@ncoast.org
  18.  
  19. Search tips
  20. ===========
  21.     To search for specific topics:  See the list of questions in the
  22. Contents section (immediately below) to find which article (part 2, 3,
  23. or 4) you need.  Then, in that part, search for that question number.
  24. For example, while you're reading part 2 of this list, the trn
  25. newsreader command "gQ203" goes to Q203.
  26.     To skip one topic and go to the next:  Search for "Q" starting in
  27. column 1.  In trn and similar newsreaders, the command "g^Q" does that.
  28.     If your newsreader doesn't support searches, you can extract these
  29. articles to a file and use your favorite editor's search commands.
  30.  
  31.  
  32. Contents--part 2 of 4
  33. =====================
  34. section 1. General questions
  35.     101. Why won't my code work?
  36.     102. What is this newsgroup about?
  37.     103. What's the difference from comp.sys.ibm.pc.programmer?
  38.     104. What other newsgroups should I know about?
  39. section 2. Compile and link
  40.     201. What the heck is "DGROUP > 64K"?
  41.     202. How do I fix "automatic data segment exceeds 64K" or "stack
  42.          plus data exceed 64K"?
  43.     203. Will Borland C code and Microsoft C code link together?
  44.     204. Why did my program bomb at run time with "floating point
  45.          formats not linked"?
  46.     205. Why did my program bomb with "floating point not loaded"?
  47.     206. How can I change the stack size in Borland's C compilers?
  48.     207. What's the format of an .OBJ file?
  49.     208. What's the format of an .EXE header?
  50.     209. What's the difference between .COM and .EXE formats?
  51. section 3. Keyboard
  52.     301. How can I read a character without echoing it to the screen,
  53.          and without waiting for the user to press the Enter key?
  54.     302. How can I find out whether a character has been typed, without
  55.          waiting for one?
  56.     303. How can I disable Ctrl-C/Ctrl-Break and/or Ctrl-Alt-Del?
  57.     304. How can I disable the print screen function?
  58.     305. How can my program turn NumLock (CapsLock, ScrollLock) on/off?
  59.     306. How can I speed up the keyboard's auto-repeat?
  60.     307. What is the SysRq key for?
  61.     308. How can my program tell what kind of keyboard is on the system?
  62.     309. How can I tell if input, output, or stderr has been redirected?
  63.  
  64.  
  65. Contents--part 3 of 4
  66. =====================
  67. section 4. Disks and files
  68.     401. What drive was the PC booted from?
  69.     402. How can I boot from drive b:?
  70.     403. Which real and virtual disk drives are valid?
  71.     404. How can I make my single floppy drive both a: and b:?
  72.     405. Why won't my C program open a file with a path?
  73.     406. How can I redirect printer output to a file?
  74.     407. How can my program open more files than DOS's limit of 20?
  75.     408. How can I read, create, change, or delete the volume label?
  76.     409. How can I get the disk serial number?
  77.     410. What's the format of .OBJ, .EXE., .COM files?
  78. section 5. Serial ports (COM ports)
  79.     501. How do I set my machine up to use COM3 and COM4?
  80.     502. How do I find the I/O address of a COM port?
  81.     503. But aren't the COM ports always at I/O addresses 3F8, 2F8, 3E8,
  82.          and 2E8?
  83.     504. How do I configure a COM port and use it to transmit data?
  84. section 6. Other hardware questions and problems
  85.     601. Which 80x86 CPU is running my program?
  86.     602. How can a C program send control codes to my printer?
  87.     603. How can I redirect printer output to a file?
  88.     604. Which video adapter is installed?
  89.     605. How do I switch to 43- or 50-line mode?
  90.     606. How can I find the Microsoft mouse position and button status?
  91.     607. How can I access a specific address in the PC's memory?
  92.     608. How can I read or write my PC's CMOS memory?
  93.     609. How can I access memory beyond 640K?
  94. section 7. Other software questions and problems
  95.     701. How can a program reboot my PC?
  96.     702. How can I time events with finer resolution than the system
  97.          clock's 55 ms (about 18 ticks a second)?
  98.     703. How can I find the error level of the previous program?
  99.     704. How can a program set DOS environment variables?
  100.     705. How can I change the switch character to - from /?
  101.     706. Why does my interrupt function behave strangely?
  102.     707. How can I write a TSR (terminate-stay-resident) utility?
  103.     708. How can I write a device driver?
  104.     709. What can I use to manage versions of software?
  105.     710. What's this "null pointer assignment" after my C program
  106.          executes?
  107.  
  108.  
  109. Contents--part 4 of 4
  110. =====================
  111. section A. Downloading
  112.     A01. What is garbo?  What is wustl?
  113.     A02. What are Simtel and "mirror sites"?  What good are they?
  114.     A03. Where do I find program <mumble>?
  115.     A04. How can I check Simtel or garbo before I post a request for a
  116.          program?
  117.     A05. How do I download and decode a program I found?
  118.     A06. Where is UUDECODE?
  119.     A07. Why do I get errors when extracting from a ZIP file I
  120.          downloaded?
  121. section B. Vendors and products
  122.     B01. How can I contact Borland?
  123.     B02. How can I contact Microsoft?
  124.     B03. What's the current version of PKZIP?
  125.     B04. What's in Borland Pascal/Turbo Pascal 7.0?
  126.     B05. What's in Microsoft C/C++ 7.0?
  127. section C. More information
  128.     C01. Are there any good on-line references for PC hardware
  129.          components?
  130.     C02. Are there any good on-line references for PC interrupts?
  131.     C03. What and where is "Ralf Brown's interrupt list"?
  132.     C04. Where can I find lex, yacc, and language grammars?
  133.     C05. What's the best book to learn programming?
  134.     C06. Where are FAQ lists archived?
  135.     C07. Where can I get the latest copy of this FAQ list?
  136.  
  137.  
  138. Acknowledgements
  139. ================
  140. Many articles posted in comp.os.msdos.programmer sparked ideas or
  141. provided information for the first version of this list.  Though I am
  142. responsible for any errors, thanks are due to the following for posted
  143. articles or private email that I used in subsequent editions:  Jamshid
  144. Afshar, Mark Aitchison, Sanjay Aiyagari, George Almasi, Aaron Auseth,
  145. Preston Bannister, Denis Beauregard, Mike Black, Glynn Brooks, Paul
  146. Brooks, Ralf Brown, Shaun Burnett, Raymond Chen, Alan Drew, Paul
  147. Ducklin, Gary Dueck, Roland Eriksson, Markus Fischer, George Forsman,
  148. B.Haible, Klaus Hartnegg, Kris Heidenstrom, Joel Hoffman, Joe Huffman,
  149. Michael Holin, Mike Iarrobino, Ajay Kamdar, Everett Kaser, Jen Kilmer,
  150. Reinhard Kirchner, Dave Kirsch, Sidney Markowitz, Jim Marks, Dimitri
  151. Matzarakis, Ken McKee, Tom Milner, Duncan Murdoch, Steve Murphy, Mert
  152. Nickerson, David Nugent, Keith Petersen, Karl Riedling, Arthur Rubin,
  153. Gerald Ruderman, Timo Salmi, Tapio Sand, John Schmid, Ajay Shah, Tom
  154. Swingle, Anders Thulin, Curt Tilmes, Ya-Gui Wei, Joe Wells, Gregory
  155. Youngblood, khill@vax1.umkc.edu, rujo@extern.uio.no
  156.  
  157. New contributors this month:  Paul Ducklin, Mike Iarrobino, Duncan
  158. Murdoch, Anders Thulin, Curt Tilmes, rujo@extern.uio.no
  159.  
  160.  
  161. Legalistic stuff
  162. ================
  163. This article is not in the public domain, but it may be redistributed so
  164. long as this notice, and the information on obtaining the latest copy of
  165. this list, are retained.  The code fragments may be used freely; credit
  166. would be appreciated but is not required.
  167.  
  168. Copyright (C) 1992  Stan Brown, Oak Road Systems.  All rights reserved.
  169.  
  170. THERE IS NO WARRANTY ON THE CODE.  I have tested all the code included
  171. below, but your machine may not work the same as mine, and my testing
  172. may not be perfect.  (Except where otherwise noted, I tested the code
  173. with both BC++ 2.0 and MSC 5.0.)
  174.  
  175. The mention of particular books or programs must not be construed to
  176. reflect unfavorably on any that are not mentioned.
  177.  
  178.  
  179. (continued in part 2)
  180. --
  181. Stan Brown, Oak Road Systems                      brown@Ncoast.ORG
  182. Cleveland, Ohio, USA
  183. Xref: bloom-picayune.mit.edu comp.os.msdos.programmer:18889 news.answers:4712
  184. Path: bloom-picayune.mit.edu!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!mcsun!uknet!doc.ic.ac.uk!agate!ames!sun-barr!cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!ncoast!brown
  185. From: brown@NCoast.ORG (Stan Brown)
  186. Newsgroups: comp.os.msdos.programmer,news.answers
  187. Subject: comp.os.msdos.programmer FAQ part 2 of 4
  188. Message-ID: <msdos-faq.921220.2@NCoast.ORG>
  189. Date: 20 Dec 92 20:13:14 GMT
  190. Expires: Wed, 3 Feb 1993 20:13:14 GMT
  191. References: <msdos-faq.921220.1@NCoast.ORG>
  192. Followup-To: comp.os.msdos.programmer
  193. Organization: Oak Road Systems, Cleveland Ohio USA
  194. Lines: 589
  195. Approved: news-answers-request@MIT.Edu
  196. Supersedes: <msdos-faq.921205.2@NCoast.ORG>
  197.  
  198. Archive-name: msdos-programmer-faq/part2
  199. Last-modified: 20 December 1922
  200.  
  201. (continued from part 1)         (no warranty on the code or information)
  202.  
  203. If the posting date is more than six weeks in the past, see instructions
  204. at the end of this article for how to get an updated copy.
  205.  
  206.             Copyright (C) 1992  Stan Brown, Oak Road Systems
  207.  
  208.  
  209. section 1. General questions
  210. ============================
  211.  
  212. Q101. Why won't my code work?
  213.  
  214.     First you need to try to determine whether the problem is in your
  215.     use of the programming language or in your use of MSDOS and your PC
  216.     hardware.  (Your manual should tell you which features are standard
  217.     and which are vendor- or MSDOS- or PC-specific.  You _have_ read
  218.     your manual carefully, haven't you?)
  219.  
  220.     If the feature that seems to be working wrong is something related
  221.     to your PC hardware or to the internals of MS-DOS, this group is the
  222.     right place to ask.  (Please check this list first, to make sure
  223.     your question isn't already answered.)
  224.  
  225.     On the other hand, if your problem is with the programming language,
  226.     the comp.lang hierarchy (including comp.lang.pascal and comp.lang c)
  227.     is probably a better resource.  Please read the other group's FAQ
  228.     list thoroughly before posting.  (These exist in comp.lang.c,
  229.     comp.lang.c++, comp.lang.modula3, comp.lang.lisp, comp.lang.perl;
  230.     they may exist in other groups as well.)  It's almost never a good
  231.     idea to crosspost between this group and a language group.
  232.  
  233.     Before posting in either place, try to make your program as small as
  234.     possible while still exhibiting the bad behavior.  Sometimes this
  235.     alone is enough to show you where the trouble is.  Also edit your
  236.     description of the problem to be as short as possible.  This makes
  237.     it look more like you tried to solve the problem on your own, and
  238.     makes people more inclined to try to help you.
  239.  
  240.     When you do post a question, it's good manners to say "email please;
  241.     I'll post a summary."  Then everybody else in the group doesn't have
  242.     to read ten virtually identical responses.  Of course, then you have
  243.     to follow through.  A summary is not simply pasting together all the
  244.     email you received.  Instead, write your own (brief) description of
  245.     the solution:  this is the best way to make sure you really
  246.     understand it.  Definitely don't repost people's cute signatures.
  247.  
  248. Q102. What is this newsgroup about?
  249.  
  250.     comp.os.msdos.programmer (comp.sys.ibm.pc.programmer until September
  251.     1990) concerns programming for MS-DOS systems.  The article "USENET
  252.     Readership report for Nov 92" in news.lists shows 42,000 readers of
  253.     this newsgroup worldwide.  Traffic was 1090.7 Kbytes (exclusive of
  254.     crossposts), comprised in 611 articles.
  255.  
  256.     Much of our traffic is about language products (chiefly from Borland
  257.     and Microsoft).  More programming topics focus on C than on any one
  258.     other language.
  259.  
  260.     Since most MS-DOS systems run on hardware that is roughly compatible
  261.     with the IBM PC, on Intel 8088, 80188, or 80x86 chips, we tend to
  262.     get a lot of questions and answers about programming other parts of
  263.     the hardware.
  264.  
  265. Q103. What's the difference from comp.sys.ibm.pc.programmer?
  266.  
  267.     c.s.i.p.programmer is the old name of comp.os.msdos.programmer, and
  268.     has been obsolete since September 1990.  However, many systems have
  269.     not removed the old group, or have removed it but aliased it to the
  270.     new name.  This means that some people still think they're posting
  271.     to c.s.i.p.programmer even though they're actually posting to
  272.     c.o.m.programmer.
  273.  
  274.     You can easily verify the non-existence of c.s.i.p.programmer by
  275.     reference to the "List of Active Newsgroups" posted to news.groups.
  276.     It's available as /pub/usenet/news.answers/active-newsgroups/part1
  277.     from the archives (see "Where are FAQ lists archived?" in section C,
  278.     "More information").
  279.  
  280. Q104. What other newsgroups should I know about?
  281.  
  282.     Your best bet is to read the periodic information postings in the
  283.     comp.binaries.ibm.pc newsgroup.  Specially helpful articles:
  284.         Using the comp.binaries.ibm.pc.d groups
  285.         Beginner's guide to binaries
  286.         Starter kit
  287.         About archives and archivers
  288.     Please wait for these articles to come around; don't post a request.
  289.  
  290.     Also check out news.announce.newusers, even if you're not a new
  291.     user.  You may be surprised how much useful information is in the
  292.     monthly postings there.  Lots of old-timers also get useful stuff
  293.     from news.newusers.questions, especially the periodic postings.
  294.  
  295.     Remember that it's good manners to subscribe to any newsgroup and
  296.     read it for a while before you post a question.  When you post, it's
  297.     also good manners to ask for replies to be emailed and then to post
  298.     a summary, which you've edited down to the absolute minimum size.
  299.  
  300.     You may also be interested in the following newsgroups.  Caution:
  301.     Some of them have specialized charters; you'll probably get (and
  302.     deserve) some flames if you post to an inappropriate group.
  303.  
  304.     - misc.forsale.computers and misc.forsale.computers.pc-clone are
  305.       where you post notices of equipment, software, or computer books
  306.       that you want to sell.  Please don't post or crosspost those
  307.       notices to comp.os.msdos.programmer.
  308.  
  309.     - comp.os.ms-windows.programmer.tools and ...misc (formerly part of
  310.       comp.windows.ms.programmer):  Similar to this group, but focus
  311.       on programming for the MS-Windows platform.
  312.  
  313.     - comp.sys.ibm.pc.hardware is for more hardware-oriented discussions
  314.       of the machines that run DOS.
  315.  
  316.     - comp.binaries.ibm.pc.wanted: AFTER you have looked in the other
  317.       groups, this is the place to post a request for a particular
  318.       binary program.
  319.  
  320.     - comp.binaries.msdos.announce (moderated) explains how to use the
  321.       archive sites, especially garbo and Simtel, and lists files
  322.       uploaded to them.  Discussions belong in comp.binaries.msdos.d,
  323.       which replaced comp.binaries.ibm.pc.archives.
  324.  
  325.     - comp.binaries.ibm.pc.d is for discussions about programs posted in
  326.       comp.binaries.ibm.pc, and only those programs.  This is a good
  327.       place to report bugs in the programs, but not to ask where to find
  328.       them (see cbip.wanted, above).  cbip.d is NOT supposed to be a
  329.       general PC discussion group.
  330.  
  331.     - comp.sources.misc: a moderated group for source code for many
  332.       computer systems.  It tends to get lots of Unix stuff, but you may
  333.       also pick up some DOS-compatible code here.
  334.  
  335.     - alt.sources: an unmoderated group for source code.  Guidelines are
  336.       posted periodically.
  337.  
  338.     - Turbo Vision is a mailing list, not a newsgroup; send email to
  339.       listserv@vtvm1.cc.vt.edu if you want to subscribe.
  340.  
  341.  
  342. section 2. Compile and link
  343. ===========================
  344.  
  345. Q201. What the heck is "DGROUP > 64K"?
  346.  
  347.     DGROUP is a link-time group of data segments, and the compiler
  348.     typically generates code that expects DS to be pointing to DGROUP.
  349.     (Exception: Borland's huge model has no DGROUP.)
  350.  
  351.     Here's what goes into DGROUP:
  352.  
  353.     - tiny model (all pointers near):  DGROUP holds the entire program.
  354.  
  355.     - small and medium models (data pointers near):  DGROUP holds all
  356.       globals and static variables including string literals, plus the
  357.       stack and the heap.
  358.  
  359.     - large, compact, and huge models in Microsoft (data pointers far):
  360.       DGROUP holds only initialized globals and static variables
  361.       including string literals, plus the stack and the near heap.
  362.  
  363.     - large and compact models in Borland (data pointers far): DGROUP
  364.       holds initialized and uninitialized globals and static variables
  365.       including string literals, but not the stack or heap.
  366.  
  367.     - huge model in Borland (data pointers far): there is no DGROUP, so
  368.       the 64K limit doesn't apply.
  369.  
  370.     In all of the above, which is to say all six models in Microsoft C
  371.     and all but huge in Borland C, DGROUP is limited to 64K including
  372.     string literals (which are treated as static data).  This limitation
  373.     is due to the Intel CPU's segmented architecture.
  374.  
  375.     See the next Q for possible remedies.
  376.  
  377.     For more information, see topics like "memory models" and "memory
  378.     management" in the index of your compiler manual.  Also see
  379.     TI738.ASC in PD1:<MSDOS.TURBO-C>BCHELP10.ZIP at Simtel for an
  380.     extended general discussion of memory usage in Borland C programs,
  381.     of which much applies to any C compiler in DOS.
  382.  
  383. Q202. How do I fix "automatic data segment exceeds 64K" or "stack plus
  384.       data exceed 64K"?
  385.  
  386.     These messages are a variation of "DGROUP > 64K".  For causes,
  387.     please see the preceding Q.
  388.  
  389.     If you get this error in tiny model, your program is simply too big
  390.     and you must use a different memory model.  If you get this link
  391.     error in models S, C, M, L, or Microsoft's H, there are some things
  392.     you can do.  (This error can't occur in Borland's huge model.)
  393.  
  394.     If you have one or two big global arrays, simply declare them far.
  395.     The compiler takes this to mean that any references to them will use
  396.     32-bit pointers, so they'll be in separate segments and no longer
  397.     part of DGROUP.
  398.  
  399.     Or you can use the /Gt[number] option with Microsoft or -Ff[=size]
  400.     with Borland C++ 2.0 and up.  This will automatically put variables
  401.     above a certain size into their own segments outside of DGROUP.
  402.  
  403.     Yet another option is to change global arrays to far pointers.  Then
  404.     at the beginning of your program, allocate them from the far heap
  405.     (_fmalloc in Microsoft, farmalloc in Borland).
  406.  
  407.     Finally, you can change to huge model (with Borland compilers, not
  408.     Microsoft).  Borland's H model still uses far pointers by default,
  409.     but "sets aside the [64K] limit" and has no DGROUP group, according
  410.     to the BC++ 2.0 Programmer's Guide.  Microsoft's H model does use
  411.     huge data pointers by default but retains DGROUP and its 64K limit,
  412.     so switching to the H model doesn't buy you anything if you have
  413.     DGROUP problems.
  414.  
  415. Q203. Will Borland C code and Microsoft C code link together?
  416.  
  417.     Typically this question is asked by someone who owns compiler A and
  418.     is trying to write code to link with a third-party library that was
  419.     compiled under compiler B.
  420.  
  421.     The answer to the question is, Not in general.  Here are some of the
  422.     reasons:
  423.  
  424.     - "Helper" functions (undocumented functions for stack checking,
  425.       floating-point arithmetic, and operations on longs) differ between
  426.       the two compilers.
  427.  
  428.     - The compilers may embed instructions in the object code that tell
  429.       the linker to look for their own run-time libraries.
  430.  
  431.     Those problems will generate link-time errors.  Others may not show
  432.     up until run time:
  433.  
  434.     - Borland's compact, large, and huge models don't assume DS=SS, but
  435.       Microsoft's do.  The -Fs option on the Borland compiler, or one of
  436.       the /A options on Microsoft, should take care of this problem --
  437.       once you know that's what's going on.
  438.  
  439.     - Check conventions for ordering and packing structure members, and
  440.       for alignment of various types on byte, word, paragraph, or other
  441.       boundaries.  Again, you can generally adjust your code to match if
  442.       you know what conventions were used in compiling the "foreign"
  443.       libraries.
  444.  
  445.     - Check the obvious and make sure that your code was compiled under
  446.       the same memory model as the code you're trying to link with.
  447.       (That's necessary, but no guarantee.  Microsoft and Borland don't
  448.       use exactly the same conventions for segments and groups,
  449.       particularly in the larger memory models.)
  450.  
  451.     That said, there are some circumstances where you can link hybrids.
  452.     Your best chance of success comes if you avoid longs and floating
  453.     point, use only 16-bit pointers, suppress stack checking, and
  454.     specify all libraries used in the link.
  455.  
  456. Q204. Why did my program bomb at run time with "floating point formats
  457.       not linked"?
  458.  
  459.     First, is that the actual message, or did it say "floating point not
  460.     loaded"?  If it was the latter, see the next Q.
  461.  
  462.     You're probably using a Borland compiler for C or C++ (including
  463.     Turbo C and Turbo C++).  Borland's compilers try to be smart and not
  464.     link in the floating-point (f-p) library unless you need it.  Alas,
  465.     they all get the decision wrong.  One common case is where you don't
  466.     call any f-p functions, but you have %f or other f-p formats in
  467.     scanf/printf calls.  The cure is to call an f-p function, or at
  468.     least force one to be present in the link.
  469.  
  470.     To do that, define this function somewhere in a source file but
  471.     don't call it:
  472.  
  473.         static void forcefloat(float *p)
  474.             { float f = *p; forcefloat(&f); }
  475.  
  476.     It doesn't have to be in the module with the main program, as long
  477.     as it's in a module that will be included in the link.
  478.  
  479.     A new solution for Borland C++ 3.0 was posted, but I don't own the
  480.     product and have not been able to verify it.  Insert these
  481.     statements in your program:
  482.  
  483.         extern unsigned _floatconvert;
  484.         #pragma extref _floatconvert
  485.  
  486. Q205. Why did my program bomb with "floating point not loaded"?
  487.  
  488.     That is Microsoft C's run-time message when the code requires a
  489.     numeric coprocessor but your computer doesn't have one installed.
  490.  
  491.     If the program is yours, relink it using the xLIBCE or xLIBCA
  492.     library (where x is the memory model).
  493.  
  494. Q206. How can I change the stack size in Borland's C compilers?
  495.  
  496.     In Turbo C, Turbo C++, and Borland C++, you may not find "stack
  497.     size" in the index but the global variable _stklen should be there.
  498.     The manual will instruct you to put a statement like
  499.  
  500.         extern unsigned _stklen = 54321U;
  501.  
  502.     in your code, outside of any function.  You must assign the value
  503.     right in the extern statement; it won't work to assign a value at
  504.     run time.  (The "extern" in this context isn't ANSI C and ought not
  505.     to be required, but the above statement is a direct quote from the
  506.     Library Reference manual of Borland C++ 2.0.)  The linker may give
  507.     you a duplicate symbol warning, which you can ignore.
  508.  
  509. Q207. What's the format of an .OBJ file?
  510.  
  511.     Here's what I've been told, though I have verified any of these
  512.     references myself:
  513.  
  514.     - base .OBJ format:  Intel's document number #121748-001, {8086
  515.       Relocatable Object Module Formats}.  (Note however that both
  516.       Microsoft and Borland formats have extended the .OBJ format.)
  517.  
  518.     - Microsoft-specific .OBJ formats:  a "Microsoft OMF Specification"
  519.       (document number ??), as well as a section in the MS-DOS
  520.       encyclopedia.
  521.  
  522.     - A "tutorial on the .OBJ format" comes with the VAL experimental
  523.       linker, which is VAL-LINK.ARC in PD1:<MSDOS.PGMUTL> at Simtel.
  524.  
  525.     If you have specific references, either to fpt-able documents or to
  526.     published works (author, title, order number or ISBN), please email
  527.     them to brown@ncoast.org for inclusion in the next edition of this
  528.     list.
  529.  
  530. Q208. What's the format of an .EXE header?
  531.  
  532.     See pages 349-350 of {PC Magazine}'s June 30, 1992 issue (xi:12) for
  533.     the old and new formats.  For a more detailed layout, look under INT
  534.     21 function 4B in Ralf Brown's interrupt list.  Ralf Brown's list
  535.     includes extensions for Borland's TLINK and Borland debugger info.
  536.  
  537.     Among the books that detail formats of executable files are {DOS
  538.     Programmer's Reference: 2d Edition} by Terry Dettman and Jim Kyle,
  539.     ISBN 0-88022-458-4; and {Microsoft MS-DOS Programmer's Reference},
  540.     ISBN 1-55615-329-5.
  541.  
  542. Q209. What's the difference between .COM and .EXE formats?
  543.  
  544.     To oversimplify:  a .COM file is a direct image of core, and an .EXE
  545.     file will undergo some further relocation when it is run (and so it
  546.     begins with a relocation header).  A .COM file is limited to 64K for
  547.     all segments combined, but an .EXE file can have as many segments as
  548.     your linker will handle and be as large as RAM can take.
  549.  
  550.     The actual file extension doesn't matter.  DOS knows that a file
  551.     being loaded is in .EXE format if its first two bytes are MZ or ZM;
  552.     otherwise it is assumed to be in .COM format.  For instance, I am
  553.     told that DR-DOS 6.0's COMMAND.COM is in .EXE format.
  554.  
  555.  
  556. section 3. Keyboard
  557. ===================
  558.  
  559. Q301. How can I read a character without echoing it to the screen, and
  560.       without waiting for the user to press the Enter key?
  561.  
  562.     The C compilers from Microsoft and Borland offer getch (or getche to
  563.     echo the character); Turbo Pascal has ReadKey.
  564.  
  565.     In other programming languages, load 8 in register AH and execute
  566.     INT 21; AL is returned with the character from standard input
  567.     (possibly redirected).  If you don't want to allow redirection, or
  568.     you want to capture Ctrl-C and other special keys, use INT 16 with
  569.     AH=10; this will return the scan code in AH and ASCII code (if
  570.     possible) in AL, except that AL=E0 with AH nonzero indicates one of
  571.     the grey "extended" keys was pressed.  (If your BIOS doesn't
  572.     support the extended keyboard, use INT 16 function 0 not 10.)
  573.  
  574. Q302. How can I find out whether a character has been typed, without
  575.       waiting for one?
  576.  
  577.     In Turbo Pascal, use KeyPressed.  Both Microsoft C and Turbo C offer
  578.     the kbhit( ) function.  All of these tell you whether a key has been
  579.     pressed.  If no key has been pressed, they return that information
  580.     to your program.  If a keystroke is waiting, they tell your program
  581.     that but leave the key in the input buffer.
  582.  
  583.     You can use the BIOS call, INT 16 function 01 or 11, to check
  584.     whether an actual keystroke is waiting; or the DOS call, INT 21
  585.     function 0B, to check for a keystroke from stdin (subject to
  586.     redirection).  See Ralf Brown's interrupt list.
  587.  
  588. Q303. How can I disable Ctrl-C/Ctrl-Break and/or Ctrl-Alt-Del?
  589.  
  590.     You can download the file PD1:<MSDOS.KEYBOARD>CADEL.ZIP from Simtel.
  591.     It contains a TSR to disable those keys, with source code in ASM.
  592.  
  593.     To disable only Ctrl-Alt-Del (actually, to change the boot keys to
  594.     leftShift-Alt-Del), use DEBOOT.COM.  Along with KEYKILL.COM, which
  595.     lets you disable up to three keys of your choice, it is at Simtel in
  596.     the file PD1:<MSDOS.KEYBOARD>KEYKILL.ARC.
  597.  
  598.     C programmers who simply want to make sure that the user can't
  599.     Ctrl-Break out of their program can use the ANSI-standard signal( )
  600.     function; the Borland compilers also offer ctrlbrk( ) for handling
  601.     Ctrl-Break.  However, if your program uses normal DOS input, the
  602.     characters ^C will appear on the screen when the user presses Ctrl-C
  603.     or Ctrl-Break.  There are many ways to work around that, including:
  604.     use INT 21 function 7, which allows redirection but doesn't display
  605.     the ^C (or echo any other character, for that matter); or use INT 16
  606.     function 0 or 10; or call _bios_keybrd( ) in MSC or bioskey( ) in
  607.     BC++; or hook INT 9 to discard Ctrl-C and Ctrl-Break before the
  608.     regular BIOS keyboard handler sees them; etc., etc.
  609.  
  610.     You should be aware that Ctrl-C and Ctrl-Break are processed quite
  611.     differently internally.  Ctrl-Break, like all keystrokes, is
  612.     processed by the BIOS code at INT 9 as soon as the user presses the
  613.     keys, even if earlier keys are still in the keyboard buffer:  by
  614.     default the handler at INT 1B is called.  Ctrl-C is not special to
  615.     the BIOS, nor is it special to DOS functions 6 and 7; it _is_
  616.     special to DOS functions 1 and 8 when at the head of the keyboard
  617.     buffer.  You will need to make sure BREAK is OFF to prevent DOS
  618.     polling the keyboard for Ctrl-C during non-keyboard operations.
  619.